Field of the Invention
The invention relates generally to methods and systems for managing remote software applications. Specifically providing a unified login experience to applications and management of application login credentials.
Description of the Related Art
Software-as-a-Service (SaaS) is a method for software deployment or delivery using the Internet, internal corporate network or similar networks. This software is generally centrally hosted, either by a service provider or by an organization. Under SaaS, a software provider licenses a software application (App) to clients for use on demand. Basic access to an App might be free of charge or with a fee. SaaS allows the provider to develop, host and operate a software application, for use by clients, who use a computer or smart device with internet access to download, if required, and run the software application and/or to access a host via a web browser or similar thin-client to run the software application. The App can be licensed to single user (one-user, one-account) or a group of users or an organization, and each user account may have many clients and/or client sessions (shared account). Some current examples of Apps include Amazon Web Services, Google Apps, Salesforce.com, Concur Travel & Expense, and Twitter.
As popularity of the SaaS model has grown, modern organizations and employees, such as individual knowledge workers, rely on an increasing number of services and Apps. Each App is typically secured with its own username and password combination, requiring users and/or organizations to keep track of the many combinations. These passwords are frequently stored insecurely, often scribbled on Post-It notes on monitors, or held in shared spreadsheets.
It is also common in some Apps to have one account that is shared by multiple users. For example, an organization will typically have one Twitter account, which will be updated and managed by many staff members. To access the account, each staff member will need to be given the username and password. This creates security concerns when a staff member leaves the organization, at which point the organization wishes to revoke the ex-member's access. This often necessitates creating a new password, which then must be redistributed to all active staff members (who then typically update their Post-It notes). The shared account and password model also complicates the use of contractors or consultants, for concerns over sharing passwords with temporary team members or outside organizations, and subsequent access revocation and password resetting.
Managing Apps with the one-user one-account model is also complicated for organizations, requiring significant time from IT administrators to setup accounts for large departments or organizations when a new App is rolled out to the organization. On-going maintenance is also challenging, as administrators try to keep, add or remove App accounts when members join and leave the organization.
Additionally, organizations typically have little to no information about which members access which Apps or when. This prevents the organizations from having traceable audit trails, required by many licensing bodies.
Existing Apps typically provide services in a one-to-one relationship with the end user, a relationship with the end user's systems and/or with the end user's organization. Integration between an end user's systems and Apps or between an end user's Apps requires pre-arranged coordination and configuration by all parties. Additionally, the Apps are not aware of each other and have no mechanism to communicate or coordinate without the participation and pre-arranged coordination of the end user and/or the end user's organization.
For example, an organization might store data in a remote spreadsheet service (for example, “Google Docs” or “Windows 365”) and want to import that data into a customer relationship management (CRM) service or marketing automation service (for example, Salesforce.com or Marketo.com, respectively). Presently, each of the mentioned services would require direct integration effort to work together, potentially involving four distinct integrations as follows: (i) Google Docs to Marketo, (ii) Google Docs to Salesforce.com, (iii) Windows 365 to Marketo, (iv) Windows 365 to Salesforce.com. The problem grows as more Apps require integration with each other and when multiple Apps simultaneously require integration with each other.
A further example would be moving press release content from a content management system (CMS) (for example, wordpress.com, squarespace.com, or tumblr.com) and sending that data to a social media service or social media management service (examples: twitter.com, facebook.com, Google+, hootsuite.com, cotweet.com, buddymedia.com). The listed examples would involve 18 different integration points—the number of integrations rises exponentially with the number of integrated applications. Solutions are desirable to streamline these operations and the others described above.